Dialog boxes in software applications are known to be useful ways of communicating information to users. Dialog boxes may be used to provide users with various forms of alerts including, for example, alerts to flag errors (e.g., in the execution or interpretation of underlying code), to indicate the need for more information (e.g., when filling out an online form), to prompt a user for a specific action (e.g., a Yes/No or other decision), etc. In many cases, only one dialog box can be opened at a time, and the simultaneous opening of a further sub-dialog box is not possible.
Limitations concerning the display of one dialog box at a time are not always troublesome. Indeed, in some instances, it is desirable to halt processing until user input is received, until a user is made aware of a possible problem, etc., thereby suggesting that the “one dialog box at a time” restriction is not really a problem in some contexts. However, this is not always the case.
Indeed, in some cases, it might be desirable to display nested or sub-dialog boxes, e.g., while processing is ongoing. As another example, it is not always possible to display sub-dialog boxes or even dialog boxes providing user hints while a first or “main” dialog box is open. In such a scenario, if a hint is desired for display (e.g., upon user request or automatic suggestion), the first dialog box has to be closed for the duration of the display of the new dialog box. The new dialog box can be displayed but, after the user is finished with it, the original dialog box has to be re-opened, potentially with the updated data. This scenario might arise, for example, when additional data based on user interactions has to be requested (e.g., to fill dialog box elements), which is quite common with today's applications. The programming therefore becomes quite complicated for the developer, as many different possibilities need to be handled and potentially hard-coded. Even dialog boxes that, for example, indicate incorrect entries to the user tend to be treated in this way and thus tend to require complicated programming.
There are approaches for displaying sub-dialog boxes in the client-server context. For instance, in some implementations, a complete JavaScript-script is created on the server and is transferred to the client. In such cases, the program logic for running the dialog box is completely on the client side. Oftentimes, these solutions run inside a web browser. A server call delivers HTML and/or JavaScript code, which is executed inside the browser environment on the client side. All dialog box code and handler functions are contained in the delivered code. When the dialog box needs to display data from the server, this data either has to be transferred in advance or by calling other methods from the client side handler functions. This approach is very often used in web applications. See, for example, U.S. Pat. No. 7,721,225, the entire content of which is hereby incorporated herein by reference.
It is believed that multiple sever-controlled dialogs cannot be opened on the client side at present, without processing program logic on the client side. Instead, a browser environment that provides form elements (e.g., a subset of dialog box controls) is needed at runtime, as is a JavaScript interpreter that executes the code transferred to the client.
Moreover, transferring the entire dialog box logic to the client also typically requires all initial data (e.g., list content) to be contained in this code. This approach therefore mixes data and logic and leads to potentially expensive server calls, for example, when complex data needs to be updated and, thus, requested from the server (e.g., because of the “long way” between the code and data). Indeed, Internet research performed by Alexa Internet, Inc., on the world's top 100 websites shows web pages including JavaScript code load times are slower than those that lack JavaScript code by 31%. Thus, it will be appreciated by those skilled in the art that there are problems with high code complexity, data and program logic intermingling, expensive server calls that take up a good deal of processing resources, and/or the like.
Thus, it will be appreciated that there is a need in the art for improved techniques for displaying dialog boxes and sub-dialog boxes that overcome some or all of these and/or other problems.
One aspect of certain example embodiments relates to techniques for displaying dialog boxes and sub-dialog boxes simultaneously, where data (and not, for example, program logic) is transferred to make this possible.
Another aspect of certain example embodiments relates to implementing control logic on a server (and not, for example, on the client), thereby providing faster access to needed data.
Another aspect of certain example embodiments relates to the server-side management of nested dialog boxes that enable users to switch from dialog box to sub-dialog box and vice-versa while still keeping the information synchronized.
Still another aspect of certain example embodiments relates to the handling of separate threads on the server side, bundling dialog and sub-dialog box data in one function, and then splitting the data on the client side for dialog and/or sub-dialog box rendering, as appropriate.
In accordance with certain example embodiments, a method for displaying dialog boxes on a client computer system is provided. When it is determined by a server computer system that a first dialog box is to be displayed on the client computer system, first dialog box data and first dialog box state data are transmitted from the server computer system to the client computer system, in order to prompt the client computer system to display the first dialog box in accordance with the first dialog box data and first dialog box state data and to make the first dialog box a currently active dialog box. Current dialog box state data associated with the currently active dialog box is received, at the server computer system and from the client computer system, following a registered change event detected via the client computer system. A dialog box function associated with the received current dialog box state data is processed, via the server computer system and independent from the client computer system. When the current dialog box state data indicates that a new sub-dialog box is to be displayed, as determined by the server computer system, the server computer system is used to: create a new server dialog box object for the new sub-dialog box; create an entry for the new server dialog box object in a registry located on the server computer system; bundle together second dialog box data and second dialog box state data for the new sub-dialog box, with the current dialog box state data and current dialog box data; and transmit the bundled together data to the client system, in order to prompt the client computer system, after the client computer system has split apart and processed the bundled together data, to display the current dialog box in accordance with the current dialog box state data and the current dialog box data, to display the new sub-dialog box in accordance with the second dialog box data and second dialog box state data, and to make the new sub-dialog box the currently active dialog box. Otherwise, any updated dialog box data and dialog state box data is transmitted to the client system, in order to prompt the client computer system to correspondingly update the display of the currently active dialog box.
In accordance with certain example embodiments, a method for displaying dialog boxes on a client computer system is provided. A main dialog box is caused to be displayed on the client computer system. A plurality of sub-dialog boxes is caused to be displayed on the client computer system, with the sub-dialog boxes and the main dialog box being linked together in parent-child modal relationships. Changes to a child box are caused to be reflected in a parent box upon the child box being closed. The client computer system includes program logic for rendering a fixed set of dialog box elements but lacks dialog box specific program logic, and the dialog box specific program logic is provided to a server computer system in communication with the client computer system.
In accordance with certain example embodiments, a dialog box/sub-dialog box control system is provided. A client device and a server device are in communication with one another via a network. The client device is configured to (a) display a first dialog box in accordance with first dialog box data and first dialog box state data received from the server device, and (b) set the first dialog box as a currently active dialog box. The client device includes at least one processor configured to at least: detect registered change events made in respect of displayed dialog boxes and displayed sub-dialog boxes; and transmit to the server device current dialog box state data associated with the currently active dialog or sub-dialog box, following detection of a registered change event. The server device includes at least one processor configured to at least: transmit first dialog box data and first dialog box state data to the client device, in order to instruct the client device to perform (a) and (b); receive the current dialog box state data transmitted from the client device; process a dialog box function associated with the received current dialog box state data. When the current dialog box state data received from the client device indicates that a new sub-dialog box is to be displayed, as determined by the server device, the at least one processor of the server device is further configured to: create a new server dialog box object for the new sub-dialog box, create an entry for the new server dialog box object in a registry located on the server device, bundle together second dialog box data and second dialog box state data for the new sub-dialog box, with the current dialog box state data, and transmit the bundled together data to the client device, in order to instruct the client device, after the client device has split apart and processed the bundled together data, to update the currently active dialog box, display the new sub-dialog box in accordance with the second dialog box data and second dialog box state data, and set the new sub-dialog box as the currently active dialog box. Otherwise, any updated dialog box data and dialog box state data is transmitted to the client device, in order to prompt the client device to correspondingly update the display of the currently active dialog box.
In certain example embodiments, non-transitory computer readable storage media tangibly store instructions that, when executed by at least one processor of a computer, may perform one of these and/or other methods.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.